Subject: re:SNA over async over X.25

From: "Jim (J.) Cobban" <[email-masked]>
Date: Thu, 21 Oct 1993 18:05:00 +0000

In message "SNA over async over X.25", 
[email-masked]' writes:

>Once approach is to get the carriers to support X.25 over async where
>the async protocol is LAPB over async as defined by ISO 3309.  This
>would require a full X.25 stack on the remote node.
>
>Does anyone know of a switch which supports this?
>
The Northern Telecom Magellan DPN-100 product has the asynch HDLC framing
support and X.25 support, but they have not been welded to one another
because of the lack of interest by the market.  

If anyone knows the answer to this question it is probably Markus Kuhn at
the University of Erlangen ([email-masked]).  he
has been strongly advocating this support for many years.  I would suggest
inviting him to join this mailing list.

Does anyone know who initiated the inclusiong of asynch HDLC into the X.25
(1992) recommendation?

>Another solution is to dial into a carrier's X.3 pad.  One approach is
>to have the PAD do some type of a link switch on the data stream.
>For example, the PAD could do a data link switch from SNA-A to
>QLLC (as some switches can switch SDLC to QLLC today).  This would
>allow a remote SNA node to connect into an existing SNA X.25 attached
>node.   Note that this is one way that NT's DPN-100 can be used today.
>Another alternative is to get the PAD to switch the link into a
>frame relay format.  This would allow a remote SNA node to connect
>with existing SNA frame relay attached nodes.
>
>These are worth pursuing.  The problem is it requires support from
>a carrier.  Perhaps if we work together as a consortium we might
>be able to generate enough interest ....

Northern Telecom switches, which are used by many public carriers, have this
capability on any processor which supports both asynch and SNA.  In most
cases the only reason why a carrier would NOT configure both services on a
processor card is memory:  They are running the asynchronous service on our
older 286 processor card which only had 1 megabyte of memory instead of the
newer cards which have 4 megabytes and a 386 processor.  Considering that
supporting SNA-A might actually reduce their packet traffic, and therefore
their revenue, they would need to have some financial justification for
turning the feature on.
>
>A second approach to using X.3 pads is to have a DLC operate over
>a switched virtual circuit between the X.3 pad and a X.25 attached
>SNA node.  The analog would be the way SNA operates over X.25 today
>using either QLLC or ELLC DLC protocols over switched or permanent
>virtual circuits.  Since the path from the remote SNA node into
>the X.3 node is unreliable, the DLC end to end protocol would have
>to provide error detection and recovery.  The advantage of this
>approach is that is adheres to CCITT standards and should be usable
>over any carrier's network.
>
>From a product point of view, using 802.2 as the DLC would
>be the easiest (taking advantage of standard MAC interfaces such
>as NDIS or ODI).  However this would  not be the most
>efficient protocol.

One disadvantage of this approach is that normally one end of the network
connection is a large mainframe or concentrator site, which must handle a
lot of traffic.  If the LLC has not been terminated in the network then this
could result in excessive overhead.  Also there are no existing products
which support 802.2 LLC2 over an X.25 VC as a SNA transport since it would
not intrinsically make sense to do so.  This last approach would make sense
if the "host" end of the connection was a TRN connection.  One mode of
operation of the NT Magellan DPN-100 product transports 802.5 MAC headers
plus LLC2 across the network between TRN accesses.  In principle that LLC2
transport could be extended across an asynchronous HDLC encapsulation, if
there were something to connect it to.
to connect it to.